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ABSTRACT 

The Command Center Network (CCN) is a computer network designed 
to interconnect a diverse group of heterogeneous shipboard information 
and Command and Control (C2) subsystems. This local network will 
utilize a single, high-speed data bus installed on the individual platform. 
As this network is envisioned, such subsystems as NTDS, NAVMACS, 
CCIS, SSES, TSA, CV-TSC, and CV-IC will be interconnected in order 
to correlate information to provide the best possible decision base for 
the commander. The Tactical Flag Command Center (TFCC) concept, 
which the CCN is essentially designed to support, is considered by the 
Navy as the nerve center of future Command and Control. The CCN 
is envisioned to be the backbone of the TFCC. This thesis examines 
the system development of the CCN. 
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INTRODUCTION 



Command and Control (C 2) may be defined as an iterative process 
of resource allocation in which a recognized point of authority coordinates 
human and machine generated information, as well as human perceptions, 
in order to perform missions and validate results. Three key points 
of the current Department of Defense position regarding Command and 
Control are: 

1) Command, control and communications ( C 3) are functions performed 
through an arrangement of personnel, equipment, facilities, 

and procedures which are employed in planning, coordinating, 
and controlling the operational activity of military forces. 

2) C3 system elements include facilities, warning systems, communi- 
cations, data collection and processing systems, and procedures. 

3) The systems approach to the development and improvement of 

C3 capabilities is essential. Subsystems need to be interoperable 
and mutually supporting. 

In considering these key points of command and control, the Navy 
perceives that one of the most critical elements of future C2 will be the 
ability of the Navy Task Force Commander to maximize his use of 
available information, and ensure that systems respond to his decisions. 
Connectivity, interoperability, flexibility, and versatility among existing 
and contemplated information and C2 subsystems are major goals of 
future developments. 



A. SYSTEMS TO SUPPORT A C2 GOAL 

As the tactical arena expands with technological advances in weaponry, 
such as Harpoon and the Cruise Missile, as well as contemplated develop- 
ments in the area of Charged Particle Beam Weapons (CPBW), correlation. 
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dissemination, and display of an accurate picture of the tactical environment 
is absolutely essential. As weapon development advances from considera- 
tions of ranges of 30 to 60 miles with weapons travelling the speed of 
sound, to ranges of hundreds of miles with weapons travelling the speed 
of light, the need for a coordinated tactical picture grows exponentially. 
Therefore, the Navy has developed the concept of the Tactical Flag 
Command Center (TFCC). The TFCC will replace the tactical commander's 
"flag plot" area. In the past, an embarked commander might have a 
designated area from which to assess the tactical situation, but the 
platform sensors immediately available to that area were limited to what 
can be accessed through an NTDS console. In the TFCC concept, the 
embarked commander would have access to all shipboard C2 and information 
subsystems through the use of two consoles. One of these would be 
used for query of various data bases and displays of charts, graphs, 
and other pertinent information. The other console would be utilized 
for an up-to-date tactical picture similar to that which is available through 
NTDS. This TFCC is envisioned as the nerve center of the Task Force 
Commander's ability to exercise command and control of forces, weapons, 
and other assigned assets. 

However, in order to correlate all the incoming data, provide an 
historical data base, display the tactical picture, control forces and 
weaponry, as well as providing general C2 functions such as reliability, 
flexibility, versatility, and security, the TFCC nerve center requires a 
system of transmission, correlation, and interchange of inputs. In a 
manner similar to that which exists in the human nervous system, a C2 
network is generally agreed upon as the best method to support the TFCC. 
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Therefore, in 1978, the Advanced Command Control Architectural 
Testbed (ACCAT) at the Naval Ocean Systems Center in San Diego, 
California, initiated the Local Command Center Network (LCCN) project. 

In essence, this project was designed to serve as the transmission 
connector and correlator for the Tactical Flag Command Center utilizing 
existing technology. In late 1979, the project name was changed to the 
Command Center Network (CCN), but the goal to serve as the backbone 
for the TFCC nerve center remained unchanged. 

Initially, this program was designed to fulfill the goal of interconnect- 
ing C2 and Navy Information subsystems to support the TFCC and produce 
a working prototype at ACCAT in twenty months. Today, over three 
years since project formulation, a working prototype at the ACCAT is 
still in the developmental stage. Meanwhile, the TFCC concept has been 
employed on the carrier USS Midway and is being implemented on the 
carrier USS America. 

B. SYSTEM CASE STUDY AND QUERIES 

The balance of this thesis is designed to outline the complexity of 
the undertaking that evolved over the course of CCN development. 

As one progresses through this presentation of the development of 
CCN, the following questions are addressed: 

1) Can worthwhile programs with a mutually agreed upon goal, 
lose sight of the need necessitating project development? 

2) Is the Command Center Network project being developed to 
respond to the perceived needs of the TFCC? 

3) Is complexity of the CCN system and technology driving this 
program, or are the system requirements the primary focus 
of the endeavor? 
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In the succeeding chapters, particular developmental aspects of the 
CCN project will be explored. Major questions like interoperability, 
internetworking, and transmission control protocols will be discussed 
to demonstrate the complexity of the project and to determine if the 
project addresses these issues in a manner that lends the intended 
support to the TFCC. In the next to last chapter, the views of the 
project manager regarding future applications of the network are given. 
These views suggest that the CCN project development may have 
wandered away from the system requirements imposed by the TFCC 
toward the development of new technologies and/or nice-to-have 
accessories. 

As this presentation progresses, one should remain aware of the 
original goal of this project and the three major questions mentioned 
earlier in this discussion. It is the author's belief that the CCN project 
has succumbed to technological temptations. In essence, the light at 
the end of the tunnel may no longer be interconnecting C2 and Navy 
Information subsystems in support of the TFCC. The light at the end of 
the tunnel may have become a runaway train of technological advances. 
The attempts to make the system climb aboard this train may have created 
a situation where interconnecting and supporting the TFCC can be 
fulfilled without the CCN. 
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INTRODUCTION TO CCN 



A. BACKGROUND 

The multi-platform commander is currently faced with the dilemma 
of an array of diverse, uncoordinated information systems designed to 
assist him in the performance of Command and Control functions. 
Therefore, the Navy has initiated the Command Center Network (CCN) 
project to address the major issues of coordinating and providing user 
access to a number of diverse subsystems which contain information of 
interest to the commander. 



B. NAVY C2 AND LOCAL NETWORKS 

Previous efforts to integrate subsystems have been impeded by the 
specificity of equipment development. Each subsystem can be charac- 
terized by unique protocols and interfaces, fully committed memories and 
central processing units, complex, expensive, system-specific software 
and intelligent human operators specifically trained to perform on the 
individual equipment. 

The goals of the Command Center Network are based on fulfilling 
three broad criteria: 

1) Improvements to Navy command and control must be evolutionary. 
That is, the present baseline of subsystems making up the Navy 
C2 system can't be wholly replaced at a given point in time; 

this is neither affordable nor is it practicable with respect to 
overhaul cycles and modernization processes with operating 
platforms and full-time operational use of shore-based command 
centers; 

2) Command and Control improvements, in order to be evolutionary 
and useful, must be compatible not only with existing systems, 
but also with expected and/or projected future installations; and 
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3) Command and Control information needs must be satisfied first 
from existing subsystem/sources (i.e. the concept of a baseline 
of system operability). [Ref. 1] 

These three criteria seem to be consistent with the system goal to 
support the TFCC. However, some debate as to whether or not a given 
system can reasonably anticipate all future developments may arise. It 
is important to note that a real danger exists if the CCN becomes too 
conscious of future developments in C2 and Information subsystems 
instead of concentrating on interconnecting existing subsystems. 

C. ISSUES 

Upon embarking on a discussion of the major issues the Command 
Center Network is designed to address, it is important to comprehend 
the context and scope of Command and Control. Command and Control 
requires informed decisions by a commander of forces in order to carry 
out assigned tasks. In that context, information becomes the essential 
element required, operated on, and disseminated by the generic functions 
of a command and control center (e.g. TFCC). The generic and inter- 
acting C2 nodal functions are: 

1) Tasking input/correlation; 

2) Information input/correlation; 

3) Situation assessment and decision making; 

4) Report generation /output; and 

5) Directive generation/output. 

Furthermore, information input consists of numerous dynamic elements 
from certain broad classes. These classes or categories of information 
input include: 
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1) own forces information (capabilities, readiness, position, etc.) 

2) threat forces information (capabilities, readiness, position, 
intentions, philosophy, etc.) 

3) environmental information (weather, sea state, visibility, 
propagation, bottom /beach /terrain characteristics, etc.), and 

4) politico-military intelligence to include postulations regarding 
force intentions based on assessment of activities. 

Within the context mentioned above, the ACCAT is developing the 
Command Center Network (CCN) to address the following issues: 

a. Can available local network technology, in combination with 
gateways (links) giving access to long-haul networks, facilitate 
the efficient and effective interconnecting of various existing 
and newly developed automated fleet subsystems so that informa- 
tion needed for command and control can be obtained from them 
within a given ship platform or from among several platforms 
and/or shore-based systems? 

b. From among the various configurations of local networks now 
known , is there one particular configuration or architecture 
that is significantly "best" for the intended application? 

c. Will application of local network technology enhance compatibility 
for expandability and evolutionary growth of the command and 
control system and supporting subsystems; that is, will it en- 
hance the ability to add and subtract subsystems as needed 

to achieve changes in capabilities? 

d. Will application of local network technology afford backward 
compatibility? 

e. What C2 nodal functions, in addition to information input, can 
be enhanced by local data network technology? 

f. What significant improvements in C2 functions can be realized 
by capitalizing on the intrinsic high band-width of local network 
technology? 

g. How well can local network technology support the distribution 
and exchange of graphic situation displays? Examples: high 
resolution bit maps of radar images, real-time handling of NTDS 
displays, real-time update of positions and identifications based 
on formatted message inputs without human intervention. 

h. What are the implied changes, if any, in C2 center procedures, 
that would result from applying local network technology? 
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i. What will comprise meaningful demonstrations of the utility of 
the planned technology application? 

j. Will connection to the network still allow for the independent 
operation of subsystems in case of busline failures? [Ref. 2] 

For the most part, these questions relate to such general C2 issues 

as flexibility, interoperability, connectivity, and versatility. It would 

seem that if these issues are addressed by and concentrated on in the 

CCN, then the project could support the TFCC in a manner consistent 

with project goals. As this presentation continues, it is important to 

consider whether the project does in fact sufficiently consider these 

issues in all aspects of system development. 

D. C2 AND NAVY INFORMATION SYSTEMS 

Figure 1 illustrates the function of the Command Center Network as 
the universal communications medium between C2 modules and Navy 
Information Systems. The acronyms used on the figure are explained 
below : 

KG - cyptological equipment 

CV-IC - contemplated development of a carrier configured 
information center subsystem 

NTDS - Navy Tactical Data System 

SSES - Ship's Signal Exploitation Space (handles processing of 
Security Agency related information) 

NAV - Navy navigation subsystems. 

E. CCN TO SUPPORT THE MULTI-PLATFORM COMMANDER 

If one can predict and control the crash landing of an orbiting 
space vehicle, why can't installed computers provide data of interest 
concerning ships in a task force? This question typifies a commonly 
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vocalized frustration of multi-platform commanders (i.e. task group, 
task force, fleet, etc.) and voices a problem with which the Navy 
continues to wrestle. [Ref. 3] 

Throughout the past fifteen years, technology has advanced the 
capability of a single ship to attack a remote target utilizing a low- 
flying missile which may have to find its way through an "obstacle 
course" of intervening platforms. This type of capability necessitates 
an extremely accurate picture of the situation. A multitude of new 
systems, from NTDS to Outlaw Shark (AN /USQ-81 (V) ) , have been de- 
signed to improve the quality of the information and provide a data 
bank for the commander. In this way, the commander is able to base 
his decisions on accurate, up-to-date information. However, integration 
and correlation of all available information to one or two displays has 
been limited in applications to the Outlaw Shark program, where three 
system installations on a single large platform has proved the most 
acceptable application of totally correlated information. Figure 2 
summarizes the functions a multi-platform commander must perform uti- 
lizing this information. Some of the considerations related to this 
information are: 

1) There is a lot of data that is needed in order to properly 
position platforms, control weapons and sensor emissions, and 
diversify all other capabilities in order to maximize force 
effectiveness. 

2) Answers to queries of the information base are needed quickly 
(typically between five and ten seconds). 

3) The tactical environment must be displayed in a manner that is 
useful and simple to comprehend. 

4) Necessary data may change rapidly, dependent on the mission, 
friendly and enemy force capabilities and the state of warfare. [Ref. 4] 
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FIGURE 2: FUNCTIONS OF THE MULTI-PLATFORM COMMANDER 



Figure 3 shows the traditional method being utilized to provide the 
necessary information to the multi-platform commander. Typically, 
responsibilities are divided in the following manner: 

1) ASW (Anti-Submarine Warfare) 

2) AAW (Anti-Air Warfare) 

3) Surface Warfare 

4) Intelligence, and 

5) Electronic Warfare. 

Other methods of assigning responsibilities are nominally at the discretion 
of the commander. The commander's staff is faced with an exponential 
growth of available data. Also, the complexity of the tactical situation 
has resulted in more sophisticated queries by the commander and the 
staff needing more timely information in order to provide quality respon- 
ses. Therefore, the staff member's memory is tasked past its limit, and 
the old grease pencil and status board approach does not lend itself to 
presentation of information that may become "stale" minutes after plotting. 

Within the next ten years, it is envisioned that the Tactical Flag 
Command Center (TFCC) will become the backbone of the distributed 
information base of the multi-platform commander. CCN is designed to 
be the interface mechanism to correlate the crush of data into a simple, 
straightforward series of displays. On a succeeding page. Figure 4 
graphically shows the enormity of the tactical information and command, 
control integration mission. 

CCN is seen by its developers as intrinsic to the correlation of 
the entire local information data base. Succeeding chapters will discuss 
how CCN will be designed and implemented to correlate the multitude of 
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FIGURE 3: THE COMMANDER AND HIS STAFF 
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FIGURE 4: TACTICAL C2/I INTEGRATION MISSION 






already employed "stand-alone" systems, which were dedicated to particular 
functions while communicating principally with a human user. Further- 
more, the set of interrogations these individual systems are designed 
to answer is based on the premise that there exists a limited, standard 
set of questions that a commander might ask. If these systems are 
interconnected, will there be a standard set of queries? To date, no 
standard set of inquiries has even been envisioned. This may imply that 
the boundaries of possible questions may not be definable. 

In essence, then, CCN must be capable of interfacing the independent 
subsystems and providing a protocol system flexible enough to respond 
to a large number and type of inquiries. [Ref. 5] 
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CCN AND RELATED TECHNOLOGY 



A. SUBSYSTEMS CONNECTED TO CCN 

Each Navy information and C2 system was developed to stand alone. 

This and the absence of a standard set of queries by the multi-platform 
commander affect CCN system design. 

When consideration is given to interconnecting such systems, one 
must consider the nature of systems designed to perform a unique set 
of functions in a stand-alone mode. Some of the characteristics of such 
stand-alone systems are as follows: 

1) Computers "talk" only to devices which understand their language. 
Since each subsystem was designed without a requirement to 
exchange data with other systems, the designer wrote programs 
which met individual subsystem needs. Thus, subsystems use 
different word lengths to describe similar parameters, have 
different symbology instructions, and employ varied protocols 

for data exchange. 

2) The cost of militarized hardware, coupled with a technology 
lag typical in all military applications has resulted in computer 
systems which generally run at or near full capacity. Typical 
of this was the recent update of the Naval Tactical Data System 
(NTDS) software which required some tradeoff considerations of 
features to be removed in order to incorporate new capabilities. 

There are severe limitations which restrict the modification of 
software within a computer in order to provide "translation" 
capabilities. 

3) The independent subsystems were designed to provide data to 
a human user. Since humans are quite adaptable, they can 
understand interference or "noisy" data and displays and, if 
necessary, repeat queries to the computer. 

4) Each subsystem can only respond to the specific set of questions 
which it is designed to answer. Each new question must, conse- 
quently, be programmed into the computer by a specialist programmer 
familiar with that particular subsystem. Current technological 
developments provide a more flexible query capability which must 
communicate in multiple "languages" in order to be used 
effectively with the Navy systems. [Ref. 6] 
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These four major characteristics are presented to show some of the 
problems which the CCN must deal with in order to interconnect existing 
and contemplated equipments. Since the early 1970's, the Navy and 
NOSC have undertaken two separate projects to provide the multi- 
platform commander with a coordinated information bank and display. 

Both of these projects fell short of the intended goal for two major 
reasons. The first was the nonexistence of a demonstrated technology 
of external query processing. The second reason was that "Command 
and Control Requirements" were constantly changing. The ever-changing 
nature of C2 requirements resulted in stagnation of the individual pro- 
jects. Therefore, incumbent on any technological effort, is the requirement 
that the command center and any other network interconnection allow 
for future additions and deletions of C2 and information subsystems. 

The ideal solution, that the commander have access to all "relevant" 

Navy subsystems, has necessitated consideration of current and future 
C2 and information subsystems in a "modular" form. 

However, in an effort to plan for the addition of future C2 and 
Navy Information subsystem modules, the goal to interconnect existing 
subsystems as a baseline to any future applications should remain 
paramount. With the development and demonstration of a CCN capability, 
standards and/or specifications can be promulgated for future subsystems, 
including a proven interface capability with the network. Therefore, 
in ascertaining whether the CCN project remains focused on its original 
goal, one must be conscious as to whether the project is designed to 
utilize existing technology to interconnect existing C2 and Navy Information 
subsystems. 
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B. SUBSYSTEM INTERFACE REQUIREMENTS 

Two distinct technologies have evolved during the past decade that 
form the basis for the CCN system. The first is the development of the 
high-speed (1-100 MBps) data bus for information transfer between 
closely grouped elements. Such a system connection allows a number of 
nodes (i.e. users and/or subsystems) to be connected through the 
same physical "wire". This connection requires the utilization of proto- 
cols so that the "wire" can transfer data between two or more users. 

Bus connections, such as that which is to be applied to the CCN, are 
already in use in single computers to tie memory and processing units 
together. They have been shown practical in systems such as SHINPADS 
(Shipboard Integrated Processing and Display System), which is the 
current Canadian Navy system for interconnecting shipboard sensors 
and weapons. 

The second technological development is the evolution of a computer 
network to connect the diverse information subsystems, while meeting 
the rigid interface requirements of the data bus. The ARPANET, a 
partial solution to the single data bus interface problem, has succeeded 
in connecting a variety of diverse computers, called "hosts". These 
computers differ greatly in type, ranging from PDP-10's and Nova 800's 
to Honeywell 6000's. Each host or node, characterized by different 
speeds, word lengths, and other characteristics, has been connected by 
a "common" language which allows them to communicate with one another. 
In essence, any user with the proper code or password may communicate 
with any of these host computers. This capability required the develop- 
ment of standardized protocols to facilitate data exchange. Additionally, 
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special software is required for each host computer to provide a transla- 
tion between computer specific protocols and the overall ARPANET 
standard protocols. Thus, the task of interconnecting different subsystems 
is technologically feasible. By substituting the high-speed data bus for 
the telephone wire utilized in the ARPANET, one interface problem is 
solved. However, in contrast to host systems in the ARPANET, existing 
Navy systems allow for no modification to individual software. [Ref. 7] 

The Command Center Network (CCN) must deal with this processing 
problem in current systems and ensure that future subsystems can 
interface with the network whether or not individual software is modified 
to accomodate standard network protocols. 

In order to demonstrate the complexity of the interfacing problem 
within the CCN, two of the proposed connected subsystems are discussed. 

The Naval Modular Automated Communications System (NAVMACS) 
integrates currently employed message communications methods and 
equipment into an automated system offering higher levels of communica- 
tion capability. It is designed to increase the speed, efficiency, and 
capability of all phases of Naval afloat and ashore communications, while 
reducing manhours and error margins. The modular concept of NAVMACS 
allows the system to be deployed according to requirements without the 
installation of total packages. This modular concept is represented by 
two major equipment configurations: NAVMACS A+ and NAVMACS V2. 

This subsystem serves as an automated shipboard terminal for a satellite 
link interfacing shore with the Common User Digital Information Exchange 
System (CUDIXS) network. NAVMACS provides automated accountability 
for all incoming and outgoing messages. Interconnection with the CCN 
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could allow the commander to determine when the last updated RAINFORM 
message was received, what the last intelligence summary emphasized, 
what time his message orders were sent, etc. One of the major functions 
of integration necessary when connection of this subsystem occurs is 
that of correlating locating data received from message traffic with 
positions held by other sensors, whether they be own platform sensors 
or from other resources available to the task force. 

Another subsystem, NTDS, consists of shipboard computers linked 
by wire to a ship's sensors and by radio data links to other ships in 
a formation, as well as to aircraft such as the E-2. If two platforms have 
the NTDS system installed, the interconnection and exchange of tactical 
information between the two is in the form of computer-to-computer 
messages. The connection is known as Link 11. If an NTDS ship 
transfers data to a non-NTDS platform, the format is via message traffic 
conveyed by radio frequency. This is called Link 14. The exchange 
of data between a ship and an aircraft like the E-2 is called Link 4A. 
Essentially, NTDS is based on the concept that sensors aboard different 
ships and/or aircraft will mutually reinforce, so that their effective 
ranges will be greatly increased, and the task force commander's tacti- 
cal picture will be enhanced and more accurate. The goal of the NTDS 
system, which is essentially to allow multiple platforms to act in concert, 
is similar to that of CCN. In order for ships to act in concert, informa- 
tion must be consistent, accurate, and highly correlated. 

Not only do the NAVMACS and NTDS subsystems provide necessary 
information to the commander, but they also are networks or part of 
other networks. The issue of interoperability must consider not only the 
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interconnectivity of such subsystems as NTDS and NAVMACS, but also 
whether or not the interconnected subsystems interfere with one another. 
Therefore, the feasibility of interconnecting networks in a CCN configu- 
ration must consider the interactions among subsystems. 

C. SUBSYSTEM INTEROPERABILITY 

Interoperability becomes a major consideration when connecting com- 
plex subsystems. Interoperability is the ability of systems, units, or 
forces to provide services to and accept services from other systems in 
such a manner that these exchanged services can operate effectively 
together. In order to be interoperable, the subsystems must operate 
in a non-interfering manner. 

Major interoperability issues are: 

1) that each of the CCN subsystems must display backward mobility, 
which means that individual subsystems may be disconnected 
from the network and operate independently from a still functional 
network, and 

2) that the connected subsystems must possess an identifiable, 
shared tactical goal or purpose. 

It is important to note that the existence of interfaces does not 
guarantee interoperability between the subsystems. Items exchanged 
through interfaces might have a positive or negative impact on the 
individual subsystems. If even some of the effects are negative, then 
an interference exists.* Therefore, for the CCN to serve the purpose 
it is designed to fulfill, the identification of all interfaces and possible 
interferences is extremely important. 

The ability to surface the aforementioned interoperability issues in 
a substantive manner as early as possible in the evolution of the CCN 

*See NAVMACS discussion, p. 38. 
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project is essential to system success. Even if all the necessary interfaces 
and interferences cannot be identified either theoretically or during 
prototype installation, the demonstration of the prototype should signifi- 
cantly address and demonstrate solutions to interoperability concerns. 

For example, some specific non-interference interoperability concerns 
are : 

1) Will the NAVMACS subsystem operate within its own network 
simultaneous with connection in the Command Center Network? 

2) Will the NTDS subsystem function efficiently as part of its own 
independent network and provide the necessary information via 
the CCN ? 

3) Will the actual performance of NAVMACS and/or NTDS, as well 
as any other subsystem, be degraded in any manner due to 
connection via the CCN? 

These questions truly address the goal of CCN to interconnect C2 
and Navy information systems to support the TFCC. To degrade the 
performance of any subsystem by connecting it to the Command Center 
Network could negate the advantages to the commander garnered from 
such a system. 
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IV. CCN PROTOCOLS AND SOFTWARE 



A. INTRODUCTION TO CCN PROTOCOLS 

The protocols necessary to carry out the functions of the CCN are 
outlined in this section. Generally speaking, a set of rules and the 
associated software to make subsystems interact (i.e. protocols), enable 
systems to communicate with one another. Protocols provide a critical 
service in any network. In the CCN, where "remote" (i.e. isolated) 
subsystems are interconnected, protocols perform such basic functions 
as the separation of various data streams, reliable sequenced message 
delivery, and the provision of system-to-system (end-to-end) flow control. 

For each C2 subsystem interfaced to the CCN, a set of programs 
is defined as user and server interacting together. Figure 5 shows 
the user and server processes as defined in the CCN. The server 
process occurs through the Network Interface Unit adjacent to the CCN 
and into the subsystem connected to that particular interface unit. The 
user process is generally considered as the actions necessary to connect 
a query into the CCN. For a given user process, there may be one 
or more server processes necessary. Appendix A explains the user and 
server process interaction in the NAVMACS subsystem. 

The user and server programs will interface to the network via a 
standard transmission control protocol (TCP). CCN utilizes TCP4, the 
accepted DOD standard for TCP's. Appendix B outlines the required 
set of user calls, commands, and user/server function codes required 
in a TCP. 
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FIGURE 5: CCN USER/SERVER PROCESS 




In addition to the standard protocols mentioned previously, protocols 
must be developed in order for the individual subsystems to be address- 
ed. These protocols must be designed so that the functions of each of 
the individual subsystems may be made available to the overall user pro- 
cess. In Appendix C, a listing of the functions of the NTDS/DTS 
subsystem is presented. In order to understand how these individual 
functions can be made available to the user. Appendix D outlines a 
typical user/server process for the NTDS/DTS subsystem. [Ref. 8] 

B. TRANSMISSION CONTROL PROTOCOL INTERFACE ISSUES 

The Transmission Control Protocol (TCP) is a protocol that has 
been proposed and utilized for process-to-process communication across 
connected computer networks. It sets up an association between two 
processes and manages the flow of data between them on a byte-based 
windowing principle. The first three major implementations of TCP 
theory were made at Stanford University, Bolt, Beranek and Newman 
(BBN) in Boston, and at University College, London. [Ref. 9] 

The use of a TCP approach stems from the fact that a critical service 
that must be provided is an end-to-end protocol for communication 
between two remote processes (i.e. subsystems in the CCN). Such a 
protocol should provide standardization of mechanisms for performing 
basic communications functions (i.e. the separation of various data 
streams, reliable sequenced message delivery, and the provision of 
end-to-end flow control). Normally, various services are built into 
lower levels in a network and those which can be provided by an end-to- 
end protocol need only be a subset of the ones necessary to communicate. 
In the ARPANET, for example, a great deal of the end-to-end flow control 
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is done by the subnet between the source and destination switching nodes 
known as IMPs. Some sample activities in this vein are flow control 
and the generation and control of various acknowledgements and error 
conditions. The unique functions of the ARPANET normal host protocol 
(NCP) are to manage the multiple connections, respond to inputs from 
IMPs, and to provide host-to-host flow control. [Ref. 10] 

For communications across connected networks like the CCN, two 
approaches to TCP may be undertaken. The first, which is utilized 
most frequently with virtual circuit networks, is to provide mappings 
between the end-to-end protocols of the various networks. Mappings 
then are performed in the "gateways" which connect networks. The 
alternative approach, which is utilized by the CCN, is the "Transport 
Station" method. In this application of TCP, there is a universal 
end-to-end protocol which generates and controls message flow in a 
standard transmit format. Packets are thereby treated as data in each 
network and are imbedded and formatted according to local network rules. 
Therefore, gateways support the transnet protocol by packet transport 
from one local net protocol to the next local net protocol. 

TCP implementations have suffered from inefficiencies in past experi- 
ments, particularly those conducted at University College, London (UCL). 
The inefficiencies seem to reinforce the need for as much attention to 
efficient implementation of communication drivers, such as TCP, as to 
any other part of the system which is frequently utilized. A study of 
the overhead of supporting ARPANET'S normal host protocol (NCP) on 
Tenex machines indicates that overhead was only 20% greater than that 
for the same traffic to local devices. [Ref. 11] 
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One can analyze the costs of implementing TCP by examination of 
the various functional areas associated with support of such a specifica- 
tion. These areas include: 

1) buffer manipulation, 

2) table searches, 

3) arithmetic computations, and 

4) choice of language. [Ref. 12] 

A more detailed presentation of these functional areas is included in 
Appendix E. 

Implementation experience suggests that all these factors must be 
taken into account. In essence, the design of TCP is one of a class of 
end-to-end protocol designs which are based on a model of several 
distinct layers of protocol. Each of these layers performs certain clearly 
defined functions. The main advantage in this approach lies in the 
simple network structure produced when all responsibility for acknowledge- 
ment, sequencing, reliable delivery, flow control, and other features are 
concentrated at one level. In order for layering to be applied successfully, 
unnecessary duplication of protocol features in more than one layer must 
be avoided. In the design of a single network, this may be possible if 
the protocol designer can assume lower level functions as given. When 
a protocol is designed for a system where internetworking occurs, this 
assumption cannot be made. Duplication of function will almost inevitably 
occur, leading to the possibility of mutual interference, which has been 
observed in experiments at University College, London. 

CCN addresses these problems by considering protocol requirements 
at each C2 and information subsystem module. Layering of protocols 
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suggests that once the user "opens" connection to a certain subsystem 
(or subsystems), a "menu" of available commands particular to the module 
will be displayed. Figure 6 shows the locations of the various protocols 
in the CCN prototype. 

Through the utilization of standard DOD transmission protocols and 
the modular approach to protocols for the interconnected subsystems, 
the CCN project has avoided many of the technological problems with 
network protocols. If an attempt had been made to expand upon the 
standard TCP or develop a new set of protocols, the CCN project might 
have become embroiled in philosophical, as well as technical, disputes as 
to how extensive a standard set of protocols should be. However, in 
this complex area, CCN remained focused on considerations involved with 
interconnecting C2 and Navy information subsystems. 

C. INTRODUCTION TO CCN SOFTWARE 

A functional description is presented for the set of programs necessary 
to interface some of the subsystems (i.e. NAVMACS and NTDS/DTS) to 
the CCN. These subsystems serve as a sample of the total program 
development necessary to initiate the CCN prototype (XDM). C2 sub- 
systems will be interfaced to the CCN by PDP 11/03 microcomputers. 

The 11/03's are also referred to as Network Interface Units or NIUs. 

The NIUs consist of a DEC LSI-11 processor, 64k bytes of random access 
memory (RAM), 4 asynchronous serial lines, a line time clock, and an 
1822 communication interface. The 1822 interface can be used to connect 
the LSI-1 1/03 to an ARPANET IMP in a direct memory access mode 
operating at 50 kilobaud. Figure 7 is a cross-sectional diagram of a 
Network Interface Unit. 
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FIGURE 7: CROSS-SECTION OF A NETWORK INTERFACE UNIT 

Source: CCN Software Design 




Existing software will be used as much as possible, especially for 
the initial CCN prototype. The NIUs employ Stanford Research Institute's 
(SRI) MOS operating system and the network protocols Telnet and TCP4. 
The remaining software that needs to be developed consists of those 
programs which interface the specific tasks associated with each sub- 
system. Current planning calls for these programs to be written in a 
higher order language called BLISS, which is somewhat similar to the 
"C" programming language. 

The following two sections outline the functions of the programs 
necessary to interconnect the NAVMACS and NTDS/DTS subsystems to 
the CCN. 

1 . NAVMACS Programs 

NAVMACS messages consist of baudot characters and are, on 
the average, 2100 characters long. The messages are delimited by a 
SOM (start of message) and EOM (end of message). Since the NAVMACS 
processor normally sends the messages to a printer, one way of control- 
ling message flow is setting the printer's ready line to a low voltage. 

Upon encountering the low voltage level, the NAVMACS processor stops 
sending the current message. When the ready line is set to a high 
voltage again, the processor sends the message in its entirety. Messages 
arrive at the NAVMACS processor over a communications link operating 
at 75 baud (100 words per minute). The NAVMACS processor sends 
the characters serially to the printer at 2400 baud. This processor has 
32k bytes of storage space available for incoming messages. If this 
space becomes full, the processor is programmed to keep new messages 
out of the system. 
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The functional requirements of NAVMACS programs include: 

- deliver NAVMACS messages to terminal users on the CCN and 
to processes like TSA and IP 

- allow a parameter indicating what kind of messages the user is 
interested in receiving (the user, throughout this discussion, 
could be a process, a terminal, or a printer) 

- require a user to login or a process to authenticate itself 

- signal a user when NAVMACS messages arrive 

- allow a user to file messages for later retrieval 

- allow a user to stop the process at any time 

- inform the user of net errors which result in loss of messages 

- convert baudot to ASCII 

- employ a multi-addressing scheme to deliver the same NAVMACS 
message to several users 

- send each NAVMACS message to the NAVMACS TT624 line 
printer 

- allow the NSM to have NAVMACS messages sent to third parties 
(the NSM can arbitrarily decide that a process or terminal on 
the CCN should receive certain NAVMACS messages) 

- filter messages based on subject or headers 

- allow the user to print out all message headers 

- inform the user when the NAVMACS processor is being held 
off (the processor is held off whenever buffer space is full 
or hardware is malfunctioning) 

- allow a terminal user to direct NAVMACS messages to a third 
party 
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- convert RAINFORM formatted messages to CCN format [Ref. 13] 

The XDM prototype at the Naval Ocean Systems Center will 

not be designed to perform all the aforementioned functions. In an 
effort to produce a working prototype at the earliest possible date, the 
initial CCN demonstration will perform only the following operations: 

- deliver NAVMACS messages 

- allow a parameter indicating the type of messages the user is 
interested in, but limited to all messages in RAINFORM format 

- signal user when NAVMACS messages arrive 

- allow the user to stop the process at any time 

- convert baudot/ASCI I 

- employ a multi-addressing scheme to deliver the same NAVMACS 
message to several users (the scheme used will be to send 

the message once for each interested user, since the TCP 
currently does not support multi-addressing) [Ref. 14] 

It is apparent from the omissions in the above list that the origi- 
nal installation of the CCN (i.e. the XDM prototype) will only touch 
the edge of the iceberg involving message processing software. 

2. NTDS/DTS Programs 

Data from the DTS computer comes in binary form over a 30-bit 
wide NTDS "slow line" to the NTDS computer. The data from/to the 
DTS is binary, with a start/stop data word and a track number for 
historical purposes. The NTDS control lines will appear to the LSI -11/03 
(Network Interface Unit) as RS-232 control lines so that the existing 
protocol (as described in NELC TM-119 Interface Design Specification) 
can be employed in the LSI- 11/03. 
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DTS programs are designed to perform the following functions: 

- deliver track data from the DTS computer to interested users 

- deliver track data from users to the DTS computer 

- require users to login and identify themselves 

- prevent transmission over CCN of track reports containing 
no change in data field 

- deliver tracks based on content (air tracks to some users, 
surface tracks to others, etc.) 

- signal the user when tracks arrive from the DTS computer 

- employ a multi-addressing scheme in order to deliver the 
same tracks to several users 

- inform users of success /failure of tracks sent to the DTS 
computer 

- convert track data from binary to ASCII 

- store track data for later retrieval 

- allow NSM to have tracks sent to a third party and filter on 
subject or content, i.e. the NSM can change the addressee 
list (for the purpose of insuring that certain processes on the 
CCN get all air track information or surface track information 
etc. ) 

- convert ASCII to binary 

- convert to /from CCN format 

- allow an option to disable the default of receiving all tracks 
and receive only certain tracks based on some filter. [Ref. 15] 

In order to demonstrate the feasibility of interconnecting DTS/NTDS 
programs in a Command Center Network, the prototype will perform the 
following operations: 
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- deliver track data from the DTS computer to interested users 

- prevent transmission over CCN of track reports containing no 
change in data fields 

- signal the user when tracks arrive from the DTS computer 

- employ a multi-addressing scheme to deliver the same tracks 
to several users 

- convert track format from binary to ASCII, and 

- convert to CCN format. [Ref. 16] 

The complexity of NTDS/DTS operations utilized on platforms 
configured with this subsystem necessitates the development of software 
to handle more operations than the XDM exhibits. In order for the 
CCN to truly interconnect NTDS in a manner sufficient to support the 
TFCC, the remainder of the program functions should be integrated in 
the prototype. 
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V. CCN PROTOTYPE (XDM) 



The architectural testbed for the Command Center Network, which 
is called the XDM, is to be installed at the ACCAT facility located at 
the C3 Site, Naval Ocean Systems Center (NOSC) in San Diego. 

Figure 8 is a conceptual diagram of the XDM installation. It shows the 
four major subsystems to be interconnected by the initial demonstration. 
The arrows in the diagram represent the contemplated flow of informa- 
tion in the XDM. 

Within the XDM, there will exist a Data Communications Network 
(DCN), which is composed of some transmission media. Access to the 
DCN will be through one of several DCN access modules (DAMS) still 
within the CCN. A number of Network Interface Unites (NIUs) will also 
be in the XDM. These NIUs provide connectivity between the XDM 
and various C2 and information modules external to the XDM. Also, a 
gateway (transmission connection link) to the ARPANET will be included. 
This is to provide interconnection to other data networks not directly 
connected by the XDM. The XDM will include a minimum of four DAMs, 
four NIUs, one gateway, and associated transmission media. 

Figure 9 shows the relationship of the aforementioned hardware in 
the XDM. 

A. XDM COALS AND DEVELOPMENT 

Design goals for the XDM fall into two major categories: 

1) Initial Development : Coals which pertain largely to qualities 

and functional capabilities of the XDM to be realized at the time 
of installation at NOSC. 
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FIGURE 9: CCN EQUIPMENT CONFIGURATION 

Source: C2 Modules for Local Command Center Network Demonstration 







2) Future Application : Coals which pertain to design characteristics 

of the initial XDM that make it readily susceptible to changes, 
modifications, or expansion of capabilities that can be expected 
to occur during its use as a testbed or prototype in the ACCAT. 
[Ref. 17] 

Initially, the XDM will interconnect selected baseline C2 and informa- 
tion subsystem modules. These modules, which perform well identified 
and defined functions in support of a command center like the TFCC, 
will be chosen from either already employed subsystems or those which 
are in the final stages of development. In this way, it is felt that the 
technology, capability, and the support of the CCN's overall goal can 
be demonstrated in a meaningful way. 

The XDM test facility is configured to accomodate integration and 
interoperability testing within guidelines published by NOSC. NOSC 
defines integration testing as that which is capable of verifying that the 
appropriate medium has been chosen for the exchange of data between 
interfaced subsystems, and that the data is appropriately merged as 
interleaved by the overall system. Interoperability testing is that which 
is capable of verifying that each participating subsystem, as well as the 
overall system, can successfully generate, transmit, receive, process, 
interpret, and control the flow of messages either internal to the system 
or those which originate from external sources. [Ref. 18] 

Implicit to the CCN concept is the isolation of users from internal 
controls, communications, and routing. Isolation of these functions 
implies the need for a network manager and programmer for each network 
installation. Those needs further complicate employment of CCN because 
of training requirements and necessary qualifications. Furthermore, 
from the developmental standpoint, the simplification of language into a 
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series of fixed commands for the user has necessitated the development 
of a higher-order language, BLISS, which ensures that communication 
with the machine or assembler languages of each of the subsystems is 
maintained. BLISS provides the interfacing language link so that the 
user can be connected to all resources running in the network. 

The distributed arrangements of many military command and control 
systems, particularly the TFCC, require intersystem protocols, whereby 
a process running on one C2 or information subsystem may have to task 
a process running on another system. The XDM must demonstrate this 
ability without causing any interference in the processes being run on 
the individual subsystems. In an employed CCN, an example of this 
capability could be where an intelligence subsystem requires access to 
messages resident in the communications subsystem message file, and 
position information resident in the navigational subsystem message file, 
and position information resident in the navigational subsystem of the 
tactical data system. Connection, data transformations, file transfers, 
etc. that are necessary for such services should all be handled by CCN 
without any need for intervention, direction, or control by the reques- 
ter. This transparency should accrue from the judicious selection and 
application of various levels and types of protocols, and is of prime 
importance in the CCN design and implementation. 

The prototype testing must also address the issues of survivability 
and modularity. With respect to CCN, survivability is the ability to 
provide network services in the event of internal failures or if subjected 
to damage or electrical interference from external sources. Modularity 
refers to the concept that separable network functions should be performed 
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by separate modules. This characteristic is often most applicable to 
software concerns, where functions are as well formed and as indepen- 
dent of each other as feasible. However, modularity also applies to 
hardware and it is intended to facilitate system changes. 

It remains a challenge to the project managers to ensure that these 
characteristics are specifically addressed in the initial demonstration 
plan. If these concerns are adequately addressed, one may conclude 
that the goal of interconnecting subsystems and supporting the TFCC 
remains paramount. However, if these issues, and solutions to them, 
are not part of the XDM demonstration, then one may conclude that a 
simple demonstration of the ability to interconnect subsystems has become 
the goal of CCN. In other words, the demonstration of technological 
feasibility may have replaced part of the original project goal of sup- 
porting the TFCC. 



B. CCN DEMONSTRATION FUNCTIONS 

The initial demonstration of the CCN will interconnect a mixture 
of existing Navy systems and developmental C2 subsystems. Although 
limited in scope, the XDM allows the demonstration of the following 
functions : 

1) Gathering of Data : A number of data sources are gathered 

through the CCN. The first data source is that which is nor- 
mally transmitted over LINK-11 and stored in the NTDS computers 
This data provides pertinent information on platforms which 
have been detected by the aggregate of sensors on the various 
task force platforms and thus provide a fairly extensive "local" 
picture. A second data source is the message traffic which is 
processed by the NAVMACS (Naval Modular Automated Communi- 
cations System). Through this channel, data from remote sources 
such as shore sites and satellites, is received by the ship. 
Effectively utilized, it can provide a larger picture of the 
environment, beyond the sensors organic to the task force. A 
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third data source included in the initial demonstration of the 
CCN is the storage of static data such as platform characteris- 
tics, rules of engagement, order of battle, etc. All three of 
these data types (local, remote, static) are stored in a single 
data base, the Data Processor of the Command Center Information 
Subsystem. 

2) Processing Data : Because of the large amount of data available, 

some processing is required to reduce it to a manageable size. 
Since the principal interest of the commander is in getting an 
accurate view of his environment, a data fusion processor has 
been implemented as part of XDM (TSA). This processor, not 

a part of the CCN development itself, incorporates algorithms 
which implement human reasoning in the fusion of data of 
different types. It is particularly useful in the identification 
of platforms which have been detected but not identified. For 
example, this processor recognizes that a ship which goes out 
of its way to stay in a storm does so to remain undetected and 
is more likely to be a warship than a merchant. Here the auto- 
mated application of human reasoning is applied to the "local" 
data provided via the Data Terminal Set and the "remote" sensor 
data provided via NAVMACS. A single, unifying picture is thus 
available to the commander, uncluttered by the multiple sources 
required to compose it. 

3) Displaying the Data : Two types of display are available to the 

user; a graphical display and an alphanumeric display. The 
graphical display provides for the user a geographic presenta- 
tion and identification of the platforms (surface, subsurface, air; 
friendly, enemy, neutral) within his area of interest. This 
geographic presentation includes a "zoom" capability which allows 
the user to either focus on a small area or to get the picture of 
a much larger surrounding area. The alphanumeric display 
allows the user to request data which is stored in the Data 
Processor. Such data can include characteristics (weapons, 
sensors, radio call sign, number of screws, etc.) of platforms 

of interest, or any other data stored in the data base. This 
alphanumeric display of data is enhanced by a natural language 
query capability which is inherent in the Query Processor of the 
Command Center Information Subsystem. This allows the user 
to ask questions in a "natural" way, eliminating the need for 
the user to be intimately aware of the computer "language" in 
order to ask questions. For example, the user may simply 
type in the question, "Show me all ships within 150 miles of the 
aircraft carrier". The response will be a listing of all such 
ships on the display. Although not a part of the CCN develop- 
ment itself, this query capability demonstrates in a powerful 
way the diversity of capabilities which can be applied once 
universal access to the data sources has been provided by the 
CCN. A third method of displaying the data is provided by the 
TT-624 printer which provides a hardcopy of any alphanumeric 
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data of interest. A typical usage would be the listing of messages 
received or some specific ship characteristics which are used 
frequently. 

4) Evaluating the Data : With the existence of the CCN (and appro- 

priate C2 modules), the commander and staff are relieved of 

the time-consuming process of accessing and manipulating data 
and are free to perform in the areas where humans excel - evalu- 
ation of data and decision-making. The decision-making process 
is a long way from automation and so the CCN serves principally 
to prepare the data in a way that the commander can make best 
use of it in assessing his alternatives. Should such automated 
techniques be developed and accepted by operational Navy person- 
nel in the future, the CCN structure will already be in place 
to easily implement it because of the basic design which support 
the modular addition of such capabilities. 

5) Disseminating Information and Orders : Through NAVMACS, 

the user can prepare and send messages to participating units. 
These messages may contain amplifying information as well as 
information. They may be either free text or formatted such 
as RA INFORM. The other capability provided by this initial 
selection of equipments is the opportunity to inject into NTDS 

a new or better track which has been determined by the data 
fusion node. For example, if the data fusion identifies a parti- 
cular ship for which only the position was previously known, 
this information may be prepared in the Link- 11 format and sent 
out via the Data Terminal Set. 

6) ARPANET Connectivity : The CCN will be connected to the secure 

ARPANET. Other secure ARPANET facilities are located at the 
Naval Postgraduate School, Fleet Numerical Weather Central 
(Monterey), Naval Research Laboratory, CINCPACFLT, Acoustic 
Research Center, and Mobile Access Terminals (MATs) which are 
located on ships. Thus remote users can connect, via telephone 
lines, directly to the CCN and thus have access to all of the 
facilities and capabilities described above. For example, a 
shipboard commander can transmit his data to the CCN and 
subsequently query the data base remotely. [Ref. 19] 

As outlined above, the demonstration of these six functional areas 
in the XDM serve as the contemplated focus for further expansion of 
the CCN to include total interconnection of all current and envisioned C2 
and Navy Information subsystems. This initial demonstration is currently 
scheduled for August or September of 1981. 
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The XDM is configured in such a manner as to adequately address 
the issues of interconnectivity and modularity. Through the utilization 
of existing technologies, the CCN prototype will demonstrate interconnec- 
tion through the correlation of information from four different subsystems. 
The modularity issue is effectively handled through the utilization of 
NIUs, which can be connected and disconnected from the data bus. 

These NIUs serve as the interface to connect subsystems to the CCN. 
However, two other issues that should be addressed by XDM are survi- 
vability and interoperability as it relates to non-interference. 

If all of these issues are addressed by XDM. then the focus of the 
CCN project remains interconnection of subsystems and support of the 
TFCC . 
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VI. CCN AND THE FUTURE 



Given that the initial CCN demonstration proves successful, the 
modular structure of the network will allow for future growth and modi- 
fication. "Universal" access to various data bases provided by the CCN 
allows for addition of other subsystems through the use of a "personality 
module" and a standard interface (both of these additions are included in 
a Network Interface Unit). C2 subsystems operating on the data bases 
can be added by conforming to standardized CCN interfaces and protocols. 

In fact, with the existence of a proven prototype of the network, 
a host of new capabilities can be investigated. Figure 10 illustrates 
some of the envisioned additions to the CCN prototype. These additions 
include: 

1) Voice to Natural Language Converter, 

2) Natural Language Processor, 

3) Text-to-Voice Synthesizer, 

4) Sophisticated Graphics and Display Devices, 

5) Multiple terminals, 

6) Telephones, 

7) Bulk Storage, 

8) Data Base Management System, 

9) Data Fusion, 

10) Alerting Elements, 

11) Microfilm Retrieval, 

12) Decision Aids, 
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13) Training/War Gaming, 

14) Key Distribution Center, 

15) Text Editing, 

16) Detailed Plans/Orders Generator, and 

17) Electronic Mail. [Ref. 20] 

Appendix F addresses each of these additions in more detail. 

This rather exhaustive list of possible applications involving the 
CCN demonstrates the potential of the program. The CCN can be the 
solution to many of the interoperability problems with current and 
envisioned Navy C2 and information subsystems. 

Dr. Glen Allgaier, the Project Manager of the CCN, envisions the 
Command Center Network of the 1990's as it appears in Figure 11. 

These ideas are, for the most part, technological subsystem additions 
to the CCN. If these additions become the focus of CCN, then applica- 
tion and employment of this system may become secondary to further 
demonstrations of the capacity to interconnect subsystems. 
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FIGURE 11: COMMAND CENTER NETWORK OF THE 1990's 

Source: Command Center Network Backbone of Future Command and Control 












VII. SUMMARY, CONCLUSIONS, AND RECOMMENDATION 



The Command Center Network (CCN) project is designed to provide 
the vital linkage between Navy C2 and information subsystems. As 
the "bus" connecting the various subsystems envisioned to encompass 
the Task Force Command Center (TFCC), CCN should be proved compati- 
ble with both shipboard and shore-based installations. Throughout this 
thesis, the complexity of certain areas of the project, such as protocol 
and software development, has been stressed in order that one can 
appreciate the enormous task facing the project developers. 

The Advanced Research Projects Administration (ARPA) has recog- 
nized the multitude of current and future research and development issues 
which must be confronted. This concern is reflected in the fact that 
ARPA insisted on the simplification of the project. Some of the concerns 
of ARPA are expressed in the following comments. 

Since many of the R & D (research and development) issues will 
surface in the future and because the total future requirements are 
not totally predictable, this testbed must be designed with a number 
of basic features. These are as follows: 

a. Flexibility : It must be possible to modify various aspects 

of the testbed (XDM) to incorporate both hardware and soft- 
ware changes. This requires that the design be modular 
and well-layered, with clearly defined interfaces. In addition, 
the software must be properly structured and well-documented; 

b. Versatility : The testbed must be capable of providing as 

broad a range of services as possible. This requires that 
the full spectrum of capabilities be provided at all levels, 
conditioned by cost and risk of development. Those features 
which were either high risk or required excessive cost are 

to be left for later investigation as R & D issues .... 

[Ref. 21] 
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Within the ARPA community, debate continues as to whether the CCN 
project is attempting to accomplish more than will ever be feasible. 

There is little disagreement that interconnecting and ultimately internet- 
working Navy C2 and information subsystems is necessary to support a 
commander in a TFCC. However, serious, basic questions remain to be 
answered by the CCN project. Some of these are expressed below. 

1) Is CCN a network in the truest sense of the concept or is it 
merely a modified tree-structure (i.e. if one of the portions of 
the bus is disconnected or damaged, are the other nodes still 
interconnected and functional)? 

2) If necessary, can the network be reconfigured at short notice 
without losing capabilities? 

3) Is CCN being developed to support a commander embarked on a 
large platform (i.e. an aircraft carrier or large amphibious 
assault platform), or can it be configured to adapt to smaller 
platforms? 

4) If CCN can be installed on smaller platforms, will one network 
installation be able to query another so that a commander can 
maximize flexible command structure, as well as command mobili- 
ty from platform to platform? 

5) In the event of emergency, can communications external to the 
locally installed CCN transfer sufficient data on request to allow 
continuity of command and control? 

6) If, as projected, the CCN intends to interconnect so many sub- 
systems, what kind of access and security structure must be 
built into the network? 

7) What kind of training, maintenance and other support logistics 
will be involved in a CCN installation? 

These are but a few of the questions that arise concerning the 
Command Center Network project. Some of these questions will be 
answered during testing of the prototype installation at NOSC. 

One must note that it is possible to sink all our technological advances 
into a system that allows neither flexibility nor versatility. This possibility 
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remains the challenge not only of the Command Center Network, but 
also for all future C2 developments. 

It is recommended that the CCN project re-examine the focus of 
the XDM demonstration. Is the focus on the need for interconnecting 
C2 and Navy information subsystems to support a tactical commander? 

If this development is to maintain its credibility in relation to this goal, 
then demonstration should be further simplified. Towards the goal of 
simplification, the author recommends starting with the interconnection 
of two existing subsystems, like NAVMACS and NTDS/DTS, and demon- 
strating the following: 

1) interconnection of all subsystem functions is feasible from a 
technological standpoint, 

2) while interconnection is made, there is no degradation of the 
individual subsystem's ability to perform in their individual 
networks, and 

3) if part of the CCN is damaged or destroyed, the remainder 
of the interconnection is still functional. 

Once the above capabilities are demonstrated, subsystems should 
be added one at a time and the testing or demonstration repeated with 
the aforementioned attributes remaining principal concerns. In this 
manner, the author feels that the goal to interconnect subsystems in 
support of the tactical commander will remain the focus of this worth- 
while project. 
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APPENDIX A 



NAVMACS USER/SERVER PROCESS 

This Appendix traces the user/server process utilized in one of 
the major subsystems connected by CCN. The NAVMACS user/server 
process is presented in this manner to demonstrate and trace how these 
processes interact in the CCN. It must be remembered that in the over- 
all CCN configuration, one user process can address one or many server 
processes. For the purpose of simplifying the discussion, the user 
process will be discussed only in reference to the NAVMACS server 
process. 

The server process reads and distributes messages the NAVMACS 
processor normally sends to its printer. The messages are distributed 
to all interested users on the CCN and may be filtered on the basis of 
message type of content (jnessages will not be filtered on content in the 
initial CCN and the only types of messages allowed will be "all" or 
"RAINFORM"). The messages are also sent to the NAVMACS printer. 
Users connect to this process via the user program described in the 
next section. The server program maintains a well known socket via a 
LISTEN call to TCP. When TCP informs this process that an attempt has 
been made by a foreign process to connect to the NAVMACS processor, 
this process will establish the type of traffic the user is interested in 
seeing by awaiting a CONTROL function code from the user process. 

If the NAVMACS processor is being held off due to lack of buffer space, 
the server will return a function code to the user (this will not take 
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place in the initial CCN). If the TYPE is acceptable, an entry will be 
made in a connection table showing: 

1. the user is connected; 

2. the TCP connection name; 

3. the type of traffic the user is interested in seeing; and 

4. a parameter to filter on; for example, a subject or header; 

5. an on/off indicator. [Ref. 22] 

An acknowledgement signal (ACK) will be returned once the connec- 
tion entry is placed into the connection table. 

As each message is received from NAVMACS, the server process will 
do some preliminary manipulating before the message is distributed. 

At first, the process will delimit the NAVMACS message by looking for 
the start of message - end of message (SOM-EOM) characters. Once 
these characters are found, the NAVMACS processor will be held off 
by dropping the ready line to a low voltage. At this time, the server 
process will convert the baudot characters to ASCII. After the conver- 
sion, the server process will attempt to send the message to the printer. 
The printer is shared so it may be busy with text from some other CCN 
user. If the printer is busy, the server process will attempt to store 
the message for the printer process to retrieve later. If no storage 
device is available, the server process will hold the message with the 
NAVMACS processor held off until the printer becomes available (in the 
initial CCN there will be no mass storage capability). The user will 
be informed via a CONTROL function code of the state of the NAVMACS 
processor. The server process will start searching the connection table 
for interested users. If the message is RAINFORM formatted, it will be 
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converted to CCN format. The CCN format is a standard tactical data 
format that makes information of this kind available to all CCN users. 

This format will be defined so that users who want to make use of, for 
example, DTS LINK-11 data can do so by recognizing the data format. 
Each connection will be examined in turn to see which ones have interest 
in the current message. If a connection is interested, the server process 
will turn it on by making an entry into the connection table. Once 
the connection table has been searched, the message processing is 
finished. 

The message will then be sent via TCP to each connection which is 
turned on. TCP will indicate the success /failure of the sent text. If 
a message cannot be delivered to a user, the user will be informed of 
the missing message by a CONTROL function code. Once TCP has 
accepted the message for transmission, the buffer space will be reused 
by turning the NAVMACS processor back on (by raising the voltage on 
the ready line high). The connection table will be reinitialized, i.e. all 
connections will be turned off. 

This process will respond to a CONTROL by updating the connection 
table entry for this user and ACKing the CONTROL. If a CLOSE is 
received from TCP, the connection table will be updated by deleting the 
entry for that connection. 

The user process will supply NAVMACS messages of a specified type 
to a user process in the CCN. The user must supply a START command 
to this process to initiate the connection to the server. The user must 
supply a TYPE parameter indicating the type of messages it wants to 
receive. The user will be able to have the messages filtered on subject 
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or header. The user process should establish that the TYPE given is 
valid. The user should supply a parameter indicating whether the 
messages are to be delivered to a specified user buffer or filed on 
mass storage. The buffer size at this time is to be on the order of 
2K bytes allowing enough room for an average size NAVMACS message. 
Once the server process responds to the attempt to connect (TCP will 
signal open), this process will send a CONTROL (type) packet. This 
CONTROL will be ACKed. This process will keep a status indication 
which reflects the state of the process at any given time (OPEN issued, 
type sent, etc.). Once the connection is established (the CONTROL 
was accepted), this process will inform the user and supply a buffer 
for incoming messages. 

Once messages arrive, they will be filed away or given to the user 
if so indicated. In either case, the user will be signalled when the 
messages arrive. The user process will delimit the messages by looking 
for SOM and EOM. The user will also be informed if the server has 
indicated that the NAVMACS processor is being held off or messages 
were lost via CONTROL function codes. This process will handle error 
messages sent by the server and will respond to a user command to 
stop at which time it will issue a CLOSE to TCP. 

The user process will also maintain a well known socket for foreign 
processes to access for the purpose of allowing third party transfer. 
Thus, the user process must be prepared to ask for login information 
and process it. Once the login is processed, this process will expect 
to receive a START command as if it were being controlled by a local 
user. 
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Terminal users will be asked to indicate what kind of NAVMACS 



messages they are interested in. This process will establish that the 
type is legitimate and that the user is authorized. If the type is not 
legitimate, the user process will return an error indication to the user. 

If the type is legitimate, this process will then connect to the server via 
TCP. This process will keep a connection status indicating the succes- 
sive states: 

1. OPEN sent 

2. TYPE sent 

3. connection established 

Once the connection is made, this process will establish the type of 
messages desired. Once the connection is established, this process will 
supply a buffer of 2K bytes for incoming messages. Once messages 
arrive, the user will be signalled of a newly arrived message. The 
terminal user can then ask for the following actions: 

1) print the message on the terminal, 

2) print the header on the terminal, and/or 

3) file the message away. 

The user will be given a time-out period in which to process the 
message before it is lost. This is necessitated by the fact that the 
user process must continually read the connection to process the header. 
A new buffer will be allocated and a new NAVMACS message solicited. 
The user may change the type of messages being delivered. The user 
process will send CONTROL (type) with the new type to the server. 

The server will return an ACK for the CONTROL. The user process 
will inform the user if the NAVMACS processor is being held off or 
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messages were lost. The terminal user can stop the process at any 
time via the DONE command. [Ref. 23] 
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APPENDIX B 



TCP SPECIFICS 



The following is a list of DOD required minimum user calls for any 
TCP: 

1. OPEN (local port, foreign socket, active/passive) 

The terms port and socket are defined in the specification. If 
the indication is passive, this call is equivalent to LISTEN. 

If there is no foreign socket specified, the LISTEN would respond 
to any attempt by a foreign process to connect. 

2. SEND (local connection name, buffer address) 

Here TCP is given the responsibility of delivering the named 
buffer to the destination. All errors due to transmission over 
the network are expected to be recovered by TCP. 

3. RECEIVE (local connection name, buffer address) 

Here TCP provides a buffer for data arriving over the network. 

4. CLOSE (local connection name) 

TCP will delete the connection. 

In the initial CCN, SRI's TCP will run in the NIUs and TOPS20 
TCP will run in the DEC 20/40. 

For users on the CCN to take advantage of the services offered 
by the CCN user processes, the following commands are defined: 

1. START 

This is the command that the user gives to the user process to 
initiate the connection to the C2 subsystem. The START command 
will allow for the following parameters: 

- name of the C2 subsystem source and destination 

- user name and password (for login purposes) 

- file name (appropriate to the operating system being used). 
This file name will provide the user process the necessary 
information to store incoming data if the user so desires. 

- filter filed: contains an indication to the user process 

of data that will be used as a filter of incoming data. For 
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example, the NSM might want to have LINK- 11 data filtered 
on content (i.e. all surface tracks and all air tracks). 

- type filed: specifies the type of data the user is interested 
in. For example, in NAVMACS this would be used to 
indicate RAINFORM type messages only are desired. 



2. DONE 

When the user is finished with the C2 subsystem, it issues this 
command to close the TCP connection and terminate the user 
process and close all files. 

3. CHANCE 

This command allows the user to change the filter or type 
specified in the START command. 

4. TRANSMIT 

This command will include a buffer address and byte count of 
data to send to the C2 subsystem. 

5. RECEIVE 

Indicates that the user is ready to process input from the C2 
subsystem. If data is available when this command is given, 
the user process will give a buffer to the user, otherwise, the 
request will be queued for processing when data does arrive. 
[Ref. 24] 

The user process will pass on to the user responses which TCP 
gives to the user process: connection established, data on connection, 
connection closed, etc. The exact nature of the responses depends 
on the TCP interfaced. For example, SRI's TCP might give one of 12 
responses to the user. These twelve responses are appropriate for the 
commands: START, DONE, TRANSMIT and RECEIVE. The user process 
will also return a success/failure indication for a CHANGE command. 

The user and server communicate with the following function codes: 

1. ACK 

The C2 packet was accepted. 

2. CONTROL 

The control function code might be used to change filters or 
to inform the user of changing events such as: printer OK or 
DTS ready. 
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3. ERROR 

This can be sent at anytime and will contain a field with an 
error code such as: printer down, DTS down, printer out of 
paper. 

4. EOF 

This marks the end of a file (in the CCN, a NAVMACS message, 
for example, is considered a file). [Ref. 25] 
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APPENDIX C 



NTDS/DTS FUNCTIONS 

The protocols contemplated for inclusion in the user process of 
the CCN are designed to access the following subsystem functions: 

- deliver track data from the DTS computer to interested users; 

- (deliver track data from users to the DTS computer) ; 

- (require users to login or processes to identify themselves) ; 

- prevent transmission over CCN of track reports containing no 
change in data fields; 

- (deliver tracks based on content (air tracks to some users, surface 
tracks to others, etc,)); 

- signal the user when tracks arrive from the DTS computer; 

- employ a multi-addressing scheme in order to deliver the same 
tracks to several users; 

- (inform users of success/failure of tracks sent to the DTS computer) ; 

- convert track data from binary to ASCII; 

- (store track data for later retrieval); 

- (allow NSM to have tracks sent to a third party and filter on 
subject or content, i.e. the NSM can change the addressee list) 

(for the purpose of insuring that certain processes on the CCN 
get all air track information or surface track information etc.); 

- (convert ASCI I /binary) ; 

- (convert to/from CCN format); and 

- (allow an option to disable the default of receiving all tracks 

and receive only certain tracks based on the same filter). [Ref. 26 ] 

The functions in parentheses are those which will be implemented by 
future protocol development. Those functions which are not in parentheses 
will be demonstrated in the CCN prototype. 
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APPENDIX D 



NTDS/DTS USER/SERVER PROCESS 

This Appendix outlines the user /server process as it relates to the 
NTDS/DTS subsystem of the CCN. 

The server process reads and distributes LINK-11 track data which 
the DTS computer normally sends to a NTDS computer. The tracks 
are sent to all interested CCN users and may be filtered on content 
(in the initial CCN no content filtering of tracks will be performed). 

Users connect to this process via the user process described in the next 
section. The server process maintains a well known socket via a LISTEN 
call to TCP. When the user process establishes a connection with this 
socket, it will send a CONTROL packet to the server. Included in the 
CONTROL message will be an indication of the user's desire to filter 
tracks. The filter may be based on content or track number (in the 
initial CCN, there will be no opportunity to filter tracks). If the 
CONTROL is acceptable, an ACK will be returned by the user process. 

A data structure will be maintained by the server consisting of one entry 
per connection containing the following type of information: 

1. user name 

2. TCP connection name 

3. filter/no filter indicator 

4. parameter to filter on 

5. on /off indicator 

As tracks arrive from the DTS, the server process will record the track 
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numbers (and other necessary information) in order that it may prevent 
transmission over CCN of track reports containing no change in the data 
fields. Due to the nature of the data receiving process, truncation of 
track data may occur before the duplicate is detected. If the newly 
arrived track is not a duplicate, a routine will be invoked to convert 
the binary track data into a CCN ASCII format. This format will be 
the standard CCN format for tactical data which will allow processes 
anywhere on the CCN to recognize and make use of the information. 

Once this conversion is done, the connection table will be scanned and 
each connection turned on /off depending on the appropriateness of the 
track. If a connection indicates some filter, the track will be analyzed 
to see if the information is pertinent to that user (in the initial CCN, 
this will not be done). The track will then be sent to all connections 
that were turned on during the scan. The connections will then be 
turned off and the process will repeat. If TCP closes the connection, 
the entry in the connection table will be deleted. 

While connected, the user will be able to send codes to the server 
process. One code will be a CONTROL (filter) so the user can change 
the filter information on its connection. The server process will respond 
by inserting the new information into the appropriate entry in the connec- 
tion table and ACKing the CONTROL. The user may also send new track 
information to the DTS computer (in the initial CCN, this will not be 
implemented). The track data will arrive in CCN ASCII format and the 
server process will convert this data to the binary format required by 
the DTS computer. The converted data will be sent to the DTS computer. 
ACK will be returned to the user process to indicate the success of 
delivering the data to the DTS. 
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The user process will supply LINK-11 track data to users on the CCN 
obtained from the DTS computer. The user must supply a START to 
this process to initiate the connection to the server process. 

Included with this command will be an indication of whether the user 
wants the data delivered to a buffer or to mass storage (in the initial 
CCN, only the KL-20/40 will have mass storage). The user can supply 
data to filter the tracks on if he so desires (in the initial CCN, no filter 
will be allowed). The user process will issue an OPEN to TCP and wait 
for TCP to signal that the connection is open. The user process will 
then send CONTROL with the filter parameters if there are any. The 
server will ACK this CONTROL. When track data arrives, the user 
process will store it in a file, if the user desires, or deliver the data 
to a specified buffer. In either case, the user will be signalled that 
LINK-11 track data has been delivered. 

The user can supply commands to the user process by requesting 
the following actions: 

1. stop the process (DONE). 

2. change the filter (CHANGE). 

3. send track data to the DTS (TRANSMIT). 

(in the initial CCN, only the DONE will be allowed) 

If the user wishes to stop the process, the user process will issue 
a CLOSE to TCP and await TCP's CLOSED response before exiting. If 
the user wishes to change the filter, a CONTROL code will be sent 
to the server process along with the new filter data. The CONTROL 
will be ACKed by the server. If the user wishes to send track data, 
it must issue a TRANSMIT along with the buffer address and byte count. 
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It is the user's responsibility to insure that data is in CCN ASCII format. 
Once data has been sent, the user process will keep an indication that 
it is awaiting acknowledgement for that data. ACKs will come from the 
server indicating the success of delivering the tracks to the DTS. 

[Ref. 27] 

The user process will also maintain a well known socket for foreign 
processes to access for the purpose of initiating third party transfer. 
Thus, the user process must be prepared to ask for and process login 
information. 
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APPENDIX E 



TCP FUNCTIONAL AREAS 



The following is a presentation and description of the four major 
functional areas associated with supporting TCP specifications: 

1. Buffer Manipulation : To make the best use of available space, 

the system caters to varying message lengths by using dynamic 
free pools of varying lengths, and the resultant frequent gar- 
bage collection. Several free pools must be accessed using the 
standard system calls (with attendant overheads) for every buffer 
request, transfer, and return to free space. This overhead 

has been found to be heavy for TCP and BBN has proposed 
that fixed buffer sizes should be used for any particular asso- 
ciation, together with reassembly direct into the user buffer. 

This approach removes the need for dynamic pools of varying 
length, and also reduces the number of transfers required. 

2. Table Searches : Associated with multiplexing connections. As 

TCP allows an association to be any unique source-destination 
address combination, no short address or index conventions are 
adapted for it. It is possible then to consume cycles in chaining 
down the connection list for each incoming message. Some 
intelligent hashing of addresses will reduce this overhead. 

3. Arithmetic Computations : TCP employs a large sequence number 

space to avoid the possibility of two letters in transit ever 
having the same sequence number. This requires 32 bit arith- 
metic to be performed both in generating a new sequence number 
and in testing that an incoming letter lies within the current 
window. Check-summing requires the same computational 
support. 

4. Choice of Language : Although the desire for a clear implemen- 

tation makes the use of a high level language attractive for 
implementing TCP, known overhead of system implementation 
languages is around 30-50% and can be much higher. Such 
overhead can be quite bearable for many applications. For a 
communications driver such as TCP, performing many actions 
per message, and even a number of actions per character, the 
cumulative effect is significant. [Ref. 27] 
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APPENDIX F 



FUTURE CCN APPLICATIONS 



This Appendix amplifies the information concerning contemplated 
additions to the CCN system listed in Chapter VI. 

a. Voice to Natural Language Convertor : This element would con- 

vert voice to text replacing a keyboard with a microphone. It 
may include the digital equivalent of a voiceprint which is 
associated with each user for security purposes. All verbal 
queries would be routed to this converter. The output of this 
element would then go to a Natural Language Processor. 

b. Natural Language Processor : This processor takes textual 

queries which are structured much as one would pose them in a 
"natural" manner, parses these queries, and restructures them 
in a format which is understood by a data base management sys- 
tem. Development of a natural language processor is currently 
being done at NOSC in the Command Center Information Subsystem 
(CCIS) project. These structured queries are then routed to 

the DBMS (Data Base Management System). 

c. Text-to-Voice Synthesizer : This element converts text to voice, 

providing the commander with verbal reports feedback to his 
queries. It basically provides the inverse of items (a) and 

(b) described above. 

d. Sophisticated Graphics and Display Devices : These will provide 

all of the advances in display technology which include: color, 
conics, shading, etc., all with a very simple user interface, 
responding to queries such as: "Show all enemy ships as a 
flashing red light". They will include large screen displays for 
purposes of briefing large groups. They will range from simple 
alphanumeric displays to high resolution displays capable of 
displaying maps and photographs with a zoom capability to show 
increasing detail. Real-time video displays will be interconnected 
via the CCN to provide conferencing and other capabilities 
which require such a display capability. 

e. Multiple Terminals : It is projected that between 100 and 200 

user terminals will be interconnected via the CCN. Each termin- 
al may have its own software and special purpose applications 
programs for utilizing the information in the CCN-connected 
data. 
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f. Telephones : Each user will have a telephone, headset or micro- 

phone for communications with other CCN users. 

g. Bulk Storage : This would be a less expensive way of storing 

vast quantities of data employing disks, tapes, or some other 
suitable bulk storage media. Generally, the information stored 
would be slowly changing in nature, not frequently accessed. 
Examples of the data might be operations orders, ship charac- 
teristics, photographs, maps, manuals, etc. The bulk storage 
may be distributed across a number of machines and would have 
a file management system for accessing and updating the stored 
data. 

h. Data Base Management System : This subsystem would manage 

all of the stored data, including that in bulk storage and micro- 
film retrieval. Capabilities of this subsystem would include: 

1. Provision for significant changes in the structure of 
the data which are transparent to the user applications 
programs. 

2. Adaptability to new data base technology. 

3. Generalization of the interface which can be mapped into 
various data base structures. 

4. Adaptability to interactive queries. 

5. Robustness in maintaining data base integrity. 

6. Optimization of queries to minimize response time. 

Thus, all queries for data from one of the C2 subsystems would 
be processed by this DBMS which would manage the organiza- 
tion of those data bases which can be managed, query the data 
base, and return the response to the inquirer. The DBMS would 
include a knowledge of the structure of the file management 
system associated with bulk storage. The DBMS would also pro- 
cess all queries to the data bases of other information systems 
and route these queries to the appropriate system. 

i. Data Fusion : This facility would take all pertinent data available 

and provide an integrated picture of all platforms (friendly, 
enemy, neutral) within the region of interest to the commander. 

In addition to the sensor reports, this fusion would consider 

such factors as political climate, positioning of platforms, personal- 
ity of commanders, known fuel supplies, behavior of platforms, 
etc. The Tactical Situation Assessment (TSA) project at NOSC is 
currently developing such a subsystem. This element would be 
highly interactive with the DBMS described in (b). 
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j. Alerting : This element monitors the data traffic on the CCN as 

well as the content of the data bases to determine if the comman- 
der needs to be alerted. Sighting of a submarine that is a 
threat to a high value unit, priority message traffic, low fuel 
supplies, and limited defensive capability due to inoperable 
aircraft are examples of alerting conditions. 

k. Microfilm Retrieval : This element would provide access to data 

which is stored on microfilm, and convert the microfilm image to 
the proper format for transmission via the CCN. 

l. Decision Aids : These may consist of a number of elements, 

performing distinct tasks as aids to the commander. This sub- 
system takes as an input the mission and objectives of the 
commander and provides optional courses of action to achieve 
them. An interactive capability will be provided, allowing the 
commander to insert his own preferences, review the explanation 
trace of the options suggested by the machine and insert his own 
options. Once an option is selected, this element summarizes 

the pros and cons, and provides a probability of success and 
losses. Examples would include: 

1. Optimum platform positioning to maximize sensor coverage. 

2. Optimum platform position for detection of enemy subma- 
rines attacking a high value unit. 

3. Optimum weapon allocation against enemy target. 

4. Optimum routing of aircraft to achieve a successful 
strike mission. 

m. Training/War Gaming : One of the significant benefits of the 

CCN, given the subsystems described to this point, is that 
it can be easily used (and learned to use) by a human while 
simultaneously providing access to all of the pertinent data 
affecting the mission of the ship. Software can thus be devel- 
oped in conjunction with the decision aids of (f) to allow war 
gaming within the actual environment of the ship. This element 
thus performs in a manner similar to that currently available 

in computer chess games of increasing complexity, and allows 
a commander and his staff to exercise in preparation for the 
real environment. 

n. Key Distribution Center : Data exchanged between subsystems 

will sometimes be of classification levels which should not be 
made available to all users of the CCN. In some cases, the 
commander may also desire to conference with certain staff mem- 
bers without allowing access to the conversation by others. 

There will thus be a facility which distributes a crypto "key" 

to each qualified participant on a message by message basis. 
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o. Text Editing : This element would contain all of those features 

which assist the commander in preparing orders or directives 
or reports which require a Textual format. The HERMES or 
MSG systems developed for the ARPANET are examples of the 
functions provided. Typical features would include addressee 
lists, special formats, spelling correction and editing capabilities. 

p. Detailed Plans/Orders Generator : This element will be used in 

the generation of detailed plans for implementing a given option 
selected in (f) above. In fact, a great deal of interaction is 
expected between these two elements as the option generator 
must understand the details of implementation in order to assess 
the probability of success. 

q. Electronic Mail : Similar to the Navy message system, it allows 

for message exchange between intraship users. 

Although all of the above functions are ones which can be imple- 
mented within a single ship environment, the CCN also provides the 
opportunity for the afloat commander to tap directly, via communications 
systems, the data bases which may be resident on shore or in systems 
which are connected to other networks such as AUTODIN-II. [Ref. 28] 
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